07 · 横向对比与选型
前六篇每篇一个范式。这篇回答：它们在同一张图上的位置在哪，遇到需求怎么选。
一、坐标系：认知功能 × 执行拓扑
把范式排成一条「从可控到自主」的线，是最常见的讲法，也是最粗的讲法 —— 它解释不了「为什么 Reflection 能叠加在 Supervisor 上」。
更准确的坐标系来自 Huang & Zhou 的 A Two-Dimensional Framework for AI Agent Design Patterns（arXiv:2605.13850，2026-03 提交 / 05 修订）。它的核心论点是：现有框架都只从单一视角描述系统 —— 要么只讲执行流，要么只讲认知操作 —— 而这两件事是正交的。
于是它拆成两根轴，交叉成 7×6 矩阵，共归纳出 28 个命名模式（其中 15 个是该文首次命名）：
| 轴 | 取值 |
|---|---|
| 认知功能（模型在干什么脑力活） | Perception 感知 ｜ Memory 记忆 ｜ Reasoning 推理 ｜ Action 行动 ｜ Reflection 反思 ｜ Collaboration 协作 ｜ Governance 治理 |
| 执行拓扑（控制流长什么形状） | Chain 链 ｜ Route 路由 ｜ Parallel 并行 ｜ Orchestrate 编排 ｜ Loop 循环 ｜ Hierarchy 层级 |
本专题的六个范式，就是这张矩阵上的六个区域：
| 本专题 | 认知功能 | 执行拓扑 |
|---|---|---|
| 01 ReAct | Reasoning + Action | Loop |
| 02 Workflow | （认知最少，模型只填空） | Chain / Route / Parallel 三种 |
| 03 Plan-and-Execute | Reasoning + Memory | Chain + Orchestrate |
| 04 Reflection | Reflection | Loop |
| 05 Supervisor | Collaboration | Orchestrate / Hierarchy |
| 06 Deep Research | Collaboration + Memory | Hierarchy + Parallel |
这张对照表解释了两件一维视角说不清的事：
① 为什么 02 一篇要讲三个东西。 因为链式、并行、路由是三种拓扑，但认知功能格子是同一个（几乎没有）。它们是同一列的三行。
② 为什么范式能叠加，不是六选一。 因为两根轴正交 —— Reflection 占的是「认知功能=反思」这一行，Supervisor 占的是「执行拓扑=层级」这一列，两者不在同一根轴上，自然能同时成立。
真实的代码 Agent 就是多个格子的叠加：
| 组成部分 | 落在哪个格子 |
|---|---|
| 读文件、改代码、跑命令的主循环 | Action × Loop |
| 复杂任务列 todo 清单 | Reasoning × Chain |
| 跑测试 → 看报错 → 改 | Reflection × Loop |
| 读大量文件时派子代理 | Collaboration × Hierarchy |
| 提交前的固定检查流程 | —— × Chain |
所以「我该用哪个范式」是错误问法。正确问法是：我这个环节缺的是哪个格子。
另一份可交叉验证的分类来自 Zhao 等的 LLM-based Agentic Reasoning Frameworks: A Survey（arXiv:2508.17692，2025-08），它按 single-agent / tool-based / multi-agent 三分。粒度比上面那张矩阵粗，但结论一致：工具使用和多智能体是两个独立的维度，不是程度差别。
二、六个范式的硬指标对比
| # | 范式 | 谁决定下一步 | 每任务模型调用 | 延迟特征 | 可预测性 | 上下文压力 | 典型死法 |
|---|---|---|---|---|---|---|---|
| 01 | ReAct | 模型，每步 | N 轮 ×1 | 随轮数累积 | 低 | 高，只增不减 | 死循环烧钱 |
| 02 | Workflow | 代码 | 固定 1~3 | 可预测 | 最高 | 低 | 分支爆炸 |
| 03 | Plan | 模型先定全局 | N+1 | +规划一轮 | 中 | 中 | 计划列完就停 |
| 04 | Reflection | 评审员 | 2 每轮 ×N 轮 | 串行倍增 | 中 | 中高 | 空转 |
| 05 | Supervisor | 主管 | 主管 N + 子代理 M×K | 可并行压缩 | 低 | 可隔离 | 为拆而拆 |
| 06 | Deep Research | 主管 + 子代理 | 数十次 | 分钟级 | 最低 | 靠压缩控制 | 永远查不完 |
两条规律：
- 01→06 成本与自主度同增，可预测性单调下降。 没有免费的智能。
- 只有 05 能真正降低单模型的上下文压力（靠隔离）。「上下文爆了」这个问题，换别的范式解决不了。
三、选型：五个判据，按顺序问
不需要决策树，五个问题按顺序问完就定了：
| 顺序 | 问题 | 答「是」 | 答「否」 |
|---|---|---|---|
| 1 | 路径能穷举吗 | → 02 Workflow，结束 | 下一问 |
| 2 | 任务会超过 10 步吗 | 下一问 | → 01 ReAct，结束 |
| 3 | 上下文会爆吗 | 下一问 | → 03 Plan |
| 4 | 子任务能并行吗 | → 05 Supervisor | → 03 + 上下文压缩 |
| 5 | 需要引用与综合报告吗 | → 06 Deep Research | 停在 05 |
| ＋ | （独立追加） 有客观验收标准，且质量比延迟重要吗 | → 叠加 04 Reflection | 别叠，会空转 |
注意第 6 问是独立的，不在主链上 —— 对应第一节说的「Reflection 在另一根轴上」。
四个真实需求走一遍：
| 需求 | 1 可穷举 | 2 >10 步 | 3 爆上下文 | 4 可并行 | 5 要引用 | 结论 |
|---|---|---|---|---|---|---|
| 客服工单分类回复 | ✅ | — | — | — | — | 02 路由。在线接口，不叠 04 |
| 修一个失败的测试 | ❌ | ❌ | — | — | — | 01 + 04，评审员是 pytest |
| 全项目日志库升级 | ❌ | ✅ | ❌ | — | — | 03 动态 todo + 04 |
| 五方案技术选型报告 | ❌ | ✅ | ✅ | ✅ | ✅ | 06 |
四个需求里只有一个真需要多智能体。这个比例大致反映现实。
四、六条跨范式结论（每条都有源码证据）
这一节是拆完六份源码后，在互不相关的代码里反复出现的模式。
4.1 给模型可改正的错误，而不是抛异常
| 出处 | 场景 | 做法 |
|---|---|---|
03 todo.py | 一轮并行调了两次清单工具 | 构造错误消息塞回历史 |
05 handoff.py | 并行交接产生非法历史 | 清掉不属于该分支的调用 |
06 deep_researcher.py | 派了 12 个，上限 5 个 | 溢出的 7 个各回一条「请用 5 个或更少再试」 |
普通程序里非法输入就该崩；Agent 编排里非法输入是模型的一次尝试，你要让它读懂并自己改正。
判据：错误信息读完，模型知道下一步怎么做吗？Invalid argument ❌ ／ 你派了 12 个但上限 5 个，请用 5 个或更少重试 ✅
4.2 消息历史合法性是隐形的第一难题
硬约束：每个工具调用必须有对应的工具结果，一个都不能少。 它在四处咬人：
| 出处 | 何时咬人 |
|---|---|
| 01 | 崩溃恢复时可能停在「调了工具没结果」的中间态 |
| 05 | 并行交接，每分支要清掉不属于自己的调用 |
| 05 | 裁剪回传时末条是工具结果，得连前面的 AI 消息一起带（[-2:]） |
| 06 | 溢出调用也必须带 tool_call_id 回一条 |
多智能体的难点不是调度，一大半时间花在维持消息历史合法。
4.3 角色必须显式隔离，否则塌缩
| 出处 | 两个角色 | 隔离手段 |
|---|---|---|
| 04 | 生成器 / 评审员 | 「evaluating only, not attempting to solve」 |
| 04 | 生成器 / 评审员 | 评审员看不到生成器的 <thoughts> |
| 05 | 主管 / 工人 | output_mode="last_message" 裁剪回传 |
| 06 | 主管 / 研究员 | 「主管协调，不做主要研究」 |
| 06 | 写手 / 引用 | 引用单独一个 Agent |
不隔离的后果：评审员自己动手改代码、主管自己去搜网页、写手为行文流畅牺牲引用精度。原理一致：一次只让模型追求一个目标。
4.4 提示词是实现的一部分
| 源码 | 提示词占比 |
|---|---|
LangChain todo.py | 34%，Python 逻辑不到 60 行 |
| Anthropic Research 主管 | 单个提示词文件 23KB |
从 03 起， 范式行为主要由提示词决定。拆这类源码要花一半时间读 prompt，只读 Python 会得出「不就是几个函数」的错误结论。
4.5 熔断要分层，一层管不住
| 出处 | 层 | 熔断对象 |
|---|---|---|
| 01 | 单 Agent | 最大步数，默认 25 |
| 04 | 反思循环 | 最大轮数（官方示例是 while True） |
| 06 | 主管 | 最大派活轮数 |
| 06 | 子研究员 | 最大工具调用数 |
| 06 | 并发 | 最大同时运行子代理数 |
| 06 | 提示词 | 「简单任务 < 5 次工具调用」 |
Anthropic 的双层设计值得抄：提示词里写预算让模型自觉，系统层再强制终止 —— 因为只靠提示词，模型一定会超。
4.6 先写理由，再给结论
| 出处 | 形式 |
|---|---|
| 02 路由 | <reasoning> 在 <selection> 前 |
| 04 生成器 | <thoughts> 在 <response> 前 |
| 06 主管 | 先显式声明题型，再派活 |
自回归模型先写出的理由会真实约束后续 token；顺序反过来完全失效，只是给已说出口的答案编说法。附带收益：reasoning 是免费的可观测性。
五、五个常见误判
| 误判 | 事实 |
|---|---|
| 「要做 Agent 就不能用 Workflow」 | 线上多数所谓 Agent 是 Workflow，且通常是对的选择 |
| 「多智能体更强」 | 它的两个理由是上下文隔离和并行，都是工程约束，与智能无关 |
| 「加个反思质量就上去」 | 没有客观验收标准的 Reflection 会空转，甚至把对的改错 |
| 「先上最灵活架构，以后好扩展」 | 反了。从 Workflow 起步，撞到具体的墙再加一层 |
| 「换范式能补模型能力」 | 补不了。换更强的模型比任何编排都有效 |
六、为什么 RL 不在这六个里
RL 不是编排。 编排改的是运行时行为，RL 改的是权重：
| 发生在 | 改变什么 | 存活多久 | |
|---|---|---|---|
| 六种编排范式 | 推理时 | 这次的行为和产出 | 本次会话 |
| RL / RLVR | 训练时 | 模型权重 | 永久 |
但 Reflection 和 RL 是同一想法的两个时间尺度 —— Reflexion 论文副标题就是 Verbal Reinforcement Learning。同一个「测试是否通过」的信号：写进上下文叫 Reflection，写进权重叫 RLVR。
所以「代码 Agent 是 Reflection 还是 RL」的答案是两个都是，在不同层。展开见 04 第八节。
七、全专题源码索引
| 篇目 | 主拆对象 | 体量 | 协议 |
|---|---|---|---|
| 01 | learn-claude-code/s01_agent_loop/code.py | 141 行 | MIT |
LangGraph chat_agent_executor.py | 1015 行 | MIT | |
| 02 | claude-cookbooks/patterns/agents/basic_workflows.ipynb | 33KB | MIT |
| 03 | langchain/.../middleware/todo.py | 357 行 | MIT |
| 04 | claude-cookbooks/.../evaluator_optimizer.ipynb | 10.8KB | MIT |
| 05 | langgraph-supervisor + langgraph-swarm 对照 | 40KB | MIT |
| 06 | Anthropic Research 提示词 + open_deep_research | 35KB + 30KB | MIT |
分类学参考：
| 资料 | 说明 |
|---|---|
| arXiv:2605.13850 | Huang & Zhou，7×6 矩阵、28 个命名模式。本篇坐标系出处 |
| arXiv:2508.17692 | Zhao 等，single-agent / tool-based / multi-agent 三分 |
| Building Effective Agents | Anthropic，Workflow / Agent 分界与五种基本模式 |
| luo-junyu/Awesome-Agent-Papers | 2,827★，持续更新的 Agent 论文索引 |
数据快照 2026-08-19，仓库数据经
gh api实测。
下一步：看范式在真实产品里怎么落地 → Multi-Agent 产品源码分析；选开发框架 → Agent 框架横向对比。